我之前去台灣在美優秀青年代表矽谷阿雅的分享會,她談到在矽谷就 "AGILE" 這一個詞每個人必須知道, 恰好沒多久前才在公司整個顧問部門季度會議時分享這個主題,迴響平平。那時候還有點大學畢業生的滿腔熱血的我有些沮喪,可能講得不夠精采也沒有扎實的經歷,不夠吸引人吧。 但之後透過參加敏捷開發相關社群活動,認識一位移民美國在微軟任職多年的前輩,他分享到 10 年前就用 Agile 的方式回大陸偏鄉導入閱讀教育軟件,因為太感動了,便開始跟他學習怎麼用 Agile 管理開發 NGO專案。
到了接下 RPA 第一個專案,從 HK 發來的 proposal 一看發現是用 SCRUM! 在先前協助 pre-sale 的過程,Agile沒什麼提及,基本上AGILE之於RPA就像魚與水一樣合拍,如果只是當成專有名詞有需要時向客人露臉亮個相,不好好實際運用的話,RPA的價值就會難以發揮。
Agile 核心就是充分了解需求並迅速解決問題的精神,把流程分成數個 Sprints 也是因為能更細節的去看到整個專案的容貌,迭代的設計不走一步到位的套路,反而是漸進式地把開發工作趨於完善, RPA 不也是一樣,沒辦法動系統和資料庫,所以 workaround 的慢慢達到理想數位自動化的目標。
切記請確實好好記錄並充分溝通,尤其在埋首開發的時候,時常會遇到迫於專案緊繃加上沒有完整 Full time 的 RPA 團隊造成固定時間的站會 Daily meeting 成效有限,太堅守型式反而對開發人員是個 burden,我之前會建議Daily meeting 的頻率可以稍微調整,但是現在我覺得每日站會絕對必須,最好趁大家還沒有吃好早餐準備工作前趕快開完會,過多的彈性在管理上會很難, team 規模不論大小都會遇到資訊傳遞中斷或誤傳和重工落拍等等 Synchronize 大家工作 這步真是不能或缺。
「迭代的設計不走一步到位的套路...沒辦法動系統和資料庫,所以 workaround 的慢慢達到理想數位自動化的目標。」-- 原作者
RPA的導入專案越來越多可能就是因為RPA加Agile的組合也許啟發了突破「舊路」的想像。
舊路就是user discussion -> prototyping -> user discussion -> product development...對一個公司的IT老臣來說前三步驟真的是惡夢,客戶意見多,protype怎麼做客戶都覺得不完整,成品最後也過於龐雜沒有人想要用。
RPA加Agile可以不用這樣,每個迭代解決的問題可以很小,而RPA又是在桌面做整合可以少去很多後端的作業,解決方案是可以快速成型並發布的。客戶再囉嗦也等到下一個迭代,而因為每個迭代都很專注在某些問題上,IT人員最討厭的客戶發散就比較好控制了。
想想當初datawarehouse和SOA專案會失敗就是因為工具太過繁複,迭代設計不良不夠小也不夠客戶中心。